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METHOD AND SYSTEM FOR THE CREATION AND 
COMMUNICATION OF NOTES CONCERNING AN AUCTION 
PARTICIPANT OR ITEM WITHIN A NETWORK-BASED AUCTION 

FACILITY 



[00011 The present application claims priority from U.S. provisional patent 
application number 60/171,821 entitled "Method and System for 
Communicating Messages Within a Network-based Auction Facility", filed 
December 21, 1999 and from U.S. provisional patent application number 
60/178,122 entitled "Method and System for the Creation and 
Communication of Notes Concerning an Auction Participant or Item Within 
a Network-based Auction Facility", filed January 26, 2000 



FIELD OF THE. INVENTION 

[0002] The present invention relates generally to the field of database 
administration and, more specifically, to a method of creating and 
communicating notes concerning an auction participant or item within a 
network-based auction facility. 



BACKGROUND OF THE INVENTION 

[0003] The administration a Web site, and specifically^ommerce Web site, 
often demands that information concerning a}^x of tools and facilities 
provided by the Web site be communkarfed between various administrative 
personnel. It is important that the^elivery mechanism for such information 
be reliable and up-to-date, as the failure to communicate information, or the 
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miscommunication of informatim, may have very serious consequences for 
a commerce Web sij:e: 

[0004] While e-mail provides one mechanism commonly used for 
conununications between administrative personnel, e-mail may not be a 
desirable solution due to the variety of the e-mail clients that may be 
employed by adnninistrative personnel and problems with e-mail delivery. 
[0005] Further, e-mail does not provide persistent or "sticky" information 
concerning an event concerning a user or item transacted via a commerce 
Web site. 



is. 
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SUMMARY OF THE INVENTION 

[0006] A method of communicating information within a network-based 
auction facility includes facilitating creation of a note pertaining to a selected 
aspect of an on-line auction facilitated by the network-based auction facility. 
The note is associated with a specific aspect of the on-line auction. A note 
indicator is displayed to indicate an association of the note with the selected 
aspect of the on-line auction when displaying information concerning the 
selected aspect on a display unit of a network device. 
[00071 Other features of the present invention will be apparent from the 
accompanying drawings and from the detailed description which follows. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0008] The present invention is illustrated by way of example and not 
limitation in the figures of the accompanying drawings, in which like 
references indicate similar elements and in which: 

[0009] Figure 1 is a bloclc diagram of an exemplary web-based facility in the 
form of a network-based auction facility. 

[0010] Figure 2 is a database diagram illustrahng an exemplary database, 
maintained by and accessed via a database engine server, that at least 
partially implements and supports the auction facility. 

[0011] Figure 3 is a diagranunatic representahon of exemplary links between 
a note record in a note table and user records and item records in respective 
user and item tables. 

[0012] Figure 4 is a diagrammatic representation of an architecture of 
exemplary applications and functions within an auction facility that facilitate 
the creation and display of notes represented by a note record. 

[0013] Figure 5 is a flow chart illustrating an exemplary method, according 
to one embodiment of the present invention, of communicating information 
via a network-based commerce facility. 
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[0014] Figure 6 illustrates an exemplary embodiment of an HTML page 
generated by a note search UL 

[0015] Figure 7 illustrates an exemplary embodiment of an HTML page 
generated by the note search UI that provides certain information regarding 
a participant located by a search string (e.g., a user). 

[0016] Figure 8 illustrates an exemplary embodiment of an HTML page 
generated by a creation UI that allows a user, or administrator, to reinstate a 
user of an auction facility following a suspension. 

[0017] Figure 9 illustrates a further exemplary embodiment of an HTML 
page generated by a note search UI that allows a user to perform a search 
specifically for notes regarding a participant or item of the auction facility. 

[0018] Figure 10 is a flow chart illustrating an exemplary method of creating 
a note, represented by a note record, within a note table. 

[0019] Figures llA - HE show various exemplary UFs, in the form of HTML 
or other mark-up language pages, that may be presented to an administrator 
in the performance of an administrative function. 



[0020] Figure 12 is a diagrammatic representation of a machine in the 
exemplary form of a computer system within which a set of instructions, for 
causing the machine to perform any of the methodologies discussed herein, 
may be executed. 
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DETAILED DESCRIPTION 

[0021] A method and system for communicating information within a 
network-based auction facility are described. In the following description, 
for purposes of explanation, numerous specific details are set forth in order 
to provide a thorough understanding of the present invention. It will be 
evident, however, to one skilled in the art that the present invention may be 
practiced without these specific details. 

[0022] For the purposes of the present specification, the term "note" shall be 
taken to refer to any textual or graphic description, comment or 
communication. The term "participant" shall be taken to refer to any entity, 
human or automated, that contributes to, or participates in, a transaction, 
communication or process. 
^ ^^.^^^^[0023] Figure 1 is block diagram illustrating an exeippl^fy Web-based 
^'^V^^ commerce facility in the form of a netwqrjp-bg^ed auction facility 10. While 



an exemplary embodiment of tljje-fJresent invention is described within the 
context of an auctiorif^erlity, it will be appreciated by those skilled in the art 
that the invepii(5n will find application many different types of computer- 
basejirmid network-based, commerce facilities. 

[0024] The auction facility 10 includes one or more of a number of types of 
front-end servers, namely page servers 12 that deliver web pages (e.g., 
markup language documents), picture servers 14 that dynamically deliver 
images to be displayed within Web pages, listing servers 16, CGI servers 18 
that provide an intelligent interface to the back-end of facility 10, and search 
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servers 20 that handle search requests to the facility 10. E-mail servers 21 
provide, inter alia, automated e-mail communications to users of the facility 
10. 

[0025] The back-end services include a datab^se^gngine server 22, a search 
index server 24 and a credit card ciat^5ase server 26, each of which 
maintains and facilitate^^at^cess to a respective database. The back-end is 
also shov^n to ipdude a number of administrative appHcations or functions 
28 thaJ>tKe described in further detail below. 

[0026] The network-based auction facility 10 may be accessed by a client 
program 30, such as a browser (e.g., the Internet Explorer distributed by 
Microsoft Corp. of Redmond, Washington) that executes on a client machine 
32 and accesses the facility 10 via a network such as, for example, the 
Internet 34. 

[0027] Figure 2 is a database diagram illustrating an exemplary datab^^e 23, 
maintain by and accessed via the database engine server 22, tfjafat least 
partially implements and supports the auction facilitv>0: The database 23 is 
a relational database, and includes a number opc^les having entries, or 
records, that are linked by indices and ke^s. Central to the database 23 is a 
user table 40, which contains ar^cmd for each user of the auction facility 10. 
A user may operate as a seller, buyer, or both, within the auction facility 10. 
The database 23 akcfmcludes item tables 42 that may be linked to the user 
table 40. Specincally, the tables 42 include a seller items table 44 and data 
items t^ble 46. A user record in the user table 40 may be linked to multiple 



items that are being, or have been, aucHoned via the faciUty lO^^^Jifik 
indicating whether the user is a seller or a bidder (or buyef) with respect to 
items for which records exist within in the item^^ables 42. The database 23 
also includes a note table 48 populated wirtinote records that may be linked 
to one or more item records withjrr^e item tables 42 and/or to one or more 
user records within the u^ef^ble 40. Each note record within the table 48 
may include, inter^^im, a comment, description, history or other information 
pertaining^icfan item being auction via the auction facility 10, or to a user of 
the adction facility 10. 

[0028] A number of other tables are also shown to be linked to the user table 
40, namely a user past aliases table 50, a feedback table 52, a bids table 54, an 
accounts table 56, and an account balances table 58. 

[0029] Figure 3 is a diagrammatic representation of exemplary links between 
a note record 60 in the note table 48, and user records 62 and item records 64 
in the respective user table 40 and item tables 42. Figure 3 also illustrates an 
exemplary structure, or fields, of the note record 60. 

[0030] As described above with reference to Figure 2, user re^ordsj62^ay be 
linked to one or more item records, the links indicating^v\^ the relevant 
user is a bidder or seller with respect to the relevant item or items. For 
example, in Figure 3, the user 4 is sho\\^6^be^elle of item 4, while user 1 
is shown to be the seller of item^-^and 2, and a bidder for item 3. 
Accordingly, a one-to-mafiy mapping, or linkage, may occur between user 
records and itepctr^cords, and the links may either the bidder or seller links. 
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[0031] The note record 60 is shown to include a number of fields, each of 
which is briefly discussed below: 

1. An identification field 66: this field contains a numeric 
identification number for note record 60. 

2. A type field 68: this field contains textual type information, 
which is selected from a predetermined set of message types 
that provides an indication of the reason for the creation of the 
note record 60. The predetermined set of message types may 
be presented, for example, to an administrator of the auction 
facility 10 for selection in the form of a drop-down menu of a 
user interface. The type information may furthermore 
constitute both primary and secondary type information, with 
the primary type information providing a broad type 
indication and the secondary type information providing a 
lower granularity of type information. As such, type 
information may be viewed as a "meta title" for a note record 
60 that corresponds to common topics for notes. Examples of 
message types that may be included within the predetermined 
set of message types include: user suspended, user received 
temporary clearance, user received procedural warning, item 
ended because copyright/ trademark violation, item ended 
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because offensive material, etc. 

3. A visibility field 70: this field contains alphanumeric visibility 
information indicating which, for example, administrators or 
level of administrator of the auction facility 10 have access to 
the relevant note record 60. 

4. A "user _ from" field 72: this field contains alphanumeric 
address information (or a key to such address information 
stored in the user table 40), indicating, for example, an address, 
or multiple addresses, of an administrator(s) that created the 
note record 60. 

5. A "user _ to" field 74: this field contains alphanumeric address 
information (or a key to such address informahon stored in the 
user table 40), indicating, for example, an address, or multiple 
addresses, of an administrator(s) to which the note record 60 is 
addressed or targeted. 

6. A "user _ about" field 76: this field contains alphanumeric 
address information (or a key to such address information 
stored in the user table 40) indicating the address of, for 
example, a user or participant of the auction facility 10 to 
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which the relevant note record 60 n\ay pertain. Such a 
participant may, it will be appreciated, be or have been either a 
bidder or a seller of items on the auction facility 10. Figure 3 
according illustrates this field as being linked, or keyed, to a 
user record 62 within the user table 40. 

7. An "item _ about" field 78: this field contains a key to an item 
record(s) 64 within the item tables 42, and accordingly 
identifies a particular item to which the note record 60 may 
pertain. In the exemplary embodiment, such items may 
include both physical products and services. The physical 
products may comprise a specialized category of products 
where the auction facility 10 is focused on such a specialized 
categories (e.g., www.art.com) or a broad range of products 
where the auction facility 10 provides a more general 
marketplace (e.g., www.ebay.com). 

8. A "when" field 80: this field contains data information 
indicating a date on which the relevant note record 60 was 
created. 

9. An "expiration" field 82: this field contains date information 
indicating an expiration date on which the relevant note record 
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60 expires. The expiration data may, for example, be inputted 
by an adnrdnistrator when creating the note record, and may 
specify a predetermined time period (e.g., one year) from the 
creation date at which the note record 60 is to expire. 

10. A "subject" field 84: this structure field contains textual 
information that is selected from a dynamic list of well-known 
subjects by a creator of the note record 60. For example, the list 
of subjects may include: suspension, warning, billing warning, 
billing authorization, etc. 

11. A "text" field 86: this field contains free-form text inputted the 
creator of the note record 60 that may provide further 
information regarding the relevant note. 

[0032] Figure 4 is a diagrammatic representation of the architecture of 
exemplary applications and functions within the auction facility 10 that 
facilitate the creahon and display of notes represented by the note record 60. 
The auction facility 10 includes a number of adnninistrative applications 28 
that may be invoked by administrators of the auction facility 10 to facilitate 
convenient and user-friendly administration through the use of notes. 
Examples of the administrative applications include an "add _ note _ about _ 
user" administrative application 90 that an administrator may invoke to 
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generate a note concerning a participant and an "add _ note _ about _ item" 
administrative application 92 that may be invoked to generate a note 
concerning an auction item. Further administrative applications 28 enable 
an administrator to create notes concerning, for example, the suspension of a 
user or item, the removal of an item that is up for auction on the auction 
facility 10, and the early ending of auction. 

[0033] Each of the administrative applications 28 may call a note Applie!^tion 
Cp^Frogmm Interface (API) 100 that embodies a note creation function/lf02, a 
note search function 104, and a note display function 105. The/\ote creation 
function 102 facilitates the storage of notes as note records^SO including the 
data elements, or fields, described above. The note creation function 102 
also allov^s note records 60 to be removed individually, or in a batch 
utilizing other criteria. The note creation function 102 also, in turn, calls one 
or more note creation User Interfaces (Urs)/l06 that each present a number 
of input fields, for example corresponding to the fields of a note record 60, 
via which a user (e.g., an administrator) can input information to populate 
the fields of a note record 60. A's mentioned above, respective sets of type 
information and subject hiformation may be presented by a creation UI 106 
as drop-down menus^A creation UI 106 may also perform a validation, or 
authentication, fur^etion by requiring an administrator to input a user ID and 
password tha^re validated before creahon of a note record 60 utilizing 
information^supplied via the relevant creation URI 106. In one embodiment, 
a creation/UI 106 may (1) display an HTML form (e.g., add note.HTML) that 
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presents a number input fields, (2) perform a further validation operation of 
the user ID and password, as well as of other information that is being 
submitted (e.g., administrator or participant^dm-ess information, subject 
information and type information), andv) if the submitted information is all 
valid, communicate this inforination to the API 100 for storage as a note 
record 60 and display a comirmation screen to the relevant administrator. If 
the validation opMa:non identifies any inputted information as being invalid 
or incorrect, thfe is communicated by the note creation UI 106 to the 
administrator. 

[0034] The note search function 104 facilitates the searching of note records 
60, within the note table 48, based on any one of a number of fields (e.g., 
administrator address or identifier, parhcipant address or identifier, item 
number, type information, subject information, etc.). The note search 
function 104, in turn, may call one or more note search User Interfaces (UI's) 
108 that present a number of input fields for specifying search criteria. As 
with the note creation UTs 106, the note search UI's 108 may perform a 
validation function by requiring an administrator to input a user ID and 
password that are validated before permitting a search operation. If the 
validation operation identifies any input information as being invalid or 
incorrect, this is communicated by the note search URI 108 to the searcher. 
[0035] Figure 5 is a flowchart illustrahng an exemplary method 110 of 
commimicating information within a network-based commerce facility, such 
as the auction facility 10. The method 110 commences at block 112 where a 
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person or process (e.g., administrator) perfornas a search of the user table 40, 
or the item tables 42, for example utilizing the note search function 104. The 
administrator may conduct such a search with a view to suspending a 
participant for a violation of rules by which the auction facility 10 operates 
or to removing an item from auction, or simply to investigate a user or item. 
The search may be conducted on any one of the fields discussed above. 
[0036] At block 114, the note search function 104, via the search UHM, 
displays textual information concerning a participant or item^dcated by the 
search. At block 116, the note search funchon 104, agajirVia the search UI 
108, displays a note icon adjacent the displayed^fe^tual information to 
indicate that at least one note, embodied;(^?ithin a note record 60, is 
associated with the located particm^t or item. In one embodiment, where 
the search URI 108 displa)^^,.-tfLe results of the search as an HTML document, 
the note icon may hay^ Uniform Resource Locator (URL) associated 
therewith wirtvtnat specifies a web or directory path to a script (e.g., a CGI 
script) t}>^invokes a note display function 105 embodied within the API 
\^ 

[0037] The note icon may further be a static or dynamic image, graphic or 
text that is visually associated the displayed information. 
[0038] At decision box 118, the note search UI 108 determines whether, for 
example, an administrator has selected the displayed note icon for the 
participant or item. For example, the search UI 108 may register a "click" or 
"double-click" operation performed by the administrator utilizing a cursor 
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control device (e.g., a mouse). If so, at block 120, the method 110 displays a 
list of notes (or messages) for the located participant or item. As described 
above, user selection of the note icon, embedded in HTML document, may 
in one embodiment invoke a note display function 105 that retrieves all note 
records 60 for the located participant or item, and populates a note display 
UI 109 (e.g., HTML page) utilizing the retrieved note records 60. 
[00391 The display of a note icon by the note search function 104 ensures that 
an administrator is presented with the option of retrieving notes, or 
messages, that administrators may have created with respect to a participant 
or item regardless of an original addressee of the note. As the note is 
associated with the subject thereof, as opposed to the addressor or 
addressee, it is ensured that any adnunistrator accessing information 
concerning the subject (e.g., a participant or item) will be made aware of the 
existence of the note. Further, as the UFs may, in one embodiment, comprise 
markup language documents (e.g., HTML documents) that are viewable by 
a browser, traditional e-mail channels for communicating administrative 
notes may be avoided. 

[0040] Figure 6 illustrates an exemplary embodiment of an HTML page 
generated by the note search UI 108, and is shown to prompt a searcher (e.g., 
an administrator) for a search string in field 122, the search string for 
example comprising the user ID of a participant. The searcher is further 
prompted to select either an exact user ID (or e-mail) match or an account ID 
search. 
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[0041] Figure 7 illustrates an exemplary embodiment of an HTMCpage 
generated by the note search UI 108 that provides certam^fuormation 
regarding a participant located by the search string^to the field 122 of the 
search URI 108 shown in Figure 6. An exenrg>lary note icon 124, which is 
associated with a URL, is displayed adj^nt the user ID of the located 
participant. The search UI 108 alsp^isplays an account balance 
(outstanding), and hypertextlmks to past and present auctions in which the 
participant participated ^as either a buyer or seller, to bids that the 
participant may have placed for items and to an alias history. The UI 108 
also provides aj^ndication whether the participant is a "top seller" within 
the auction/facility 10. Finally, the UI 108 provides a number of user- 
selectable actions (e.g., reinstate) that invoke an administrative application 
28/such as any of those discussed above with reference to Figure 4. 
[0042] Figure 8 illustrates an exemplary embodiment of an HTML page 
generated by a creation UI 106 that allows a user, or an administrator, to 
reinstate a viser of the auction facility 10, following a suspension. The UI 106 
may, in one embodiment, interact with a reinstate function (not shown) that 
records the reinstating of a user and that interacts with a note creation 
function 102 to automatically create a note concerning the reinstatement 
within the note table 48. The UI 106 shown in Figure 8 may be generated 
responsive to user selection of a "reinstate" hypertext link 126 shown in 
Figure 7. The UI 106 presents a user ID field 130 into which the 
administrator enters an identifier or e-mail address, a password field 132 
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into which the administrator enters a password, a user field 134 into which 
the administrator enters a user ID or e-mail address concerning the user to 
be reinstated, a "warning reason" drop-down menu 136 that contains a 
predetermined set of reasons why a user of the auction facility 10 may be 
warned (e.g., a list of common infractions), and a text field 140 into which 
the administrator can input further information regarding the reinstatement. 
For example, the administrator may indicate that a case of mistaken identity 
caused the relevant user to be blocked or removed from the auction facility 
10. The UI 106 also includes a "reinstate" button 142 that is user selectable to 
invoke a reinstate function, and a "clear form" button 144 that is user 
selectable to reset the contents of the fields 130 - 140. 
[0043] Figure 9 illustrates a further exemplary embodiment of an HTML 
page generated by the note search UI 108 that allows, for example, a user to 
perform a search specifically for notes regarding a participant or item of the 
auction facility 10. To this end, the exemplary UI 108 includes an "about" 
field 150 into which an administrator may enter a user ID, an e-mail address 
or an item number to identify either a participant or item number to identify 
either a participant or an item. Alternatively, the adnrunistrator may leave 
the field 150 blank so that the search results are not filtered according to 
participant or item. 

[0044] A "note category" field 152 provides a drop-down menu of note 
categories that are user selectable to locate notes pertaining only to a specific 
category. For example, the drop-down menu presented within the field 152 
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may specify a "reinstate" category that is user selectable to identify notes 
pertaining to reinstatement actions formed by administrators. It will be 
appreciated that categories into which notes may be organized is dependent 
on the type of facility being administered, and also upon the design of the 
auction facility 10. Accordingly, a wide variety of categories could be 
presented for selection as input to the "note category" field 152. 
[0045] Figure 10 is a flow chart illustrating an exemplary method 160 of 
creating a note, represented by a note record 60, within the note table 48. 
The method 160 commences with the invoking of the note creation function 
102. The note creation function 102 may be invoked by a user via any one of 
a number of administrative interfaces (e.g., interfaces to end an auction, 
suspend the seller, reinstate a seller, etc.). Alternatively, the note creation 
function 102 may be invoked automahcally by an automated administrative 
function that, merely for example, performs a housekeeping function with 
respect to the database 23. The note creation function 102 may also be 
invoked by a batch function that performs certain batch functions with 
respect to the database 23 (e.g., the pruning of inactive accounts, etc.). 
Examples of administrative applications that may invoke the note creation 
function 102 are provided in Figure 4. 

[0046] At block 164, the administrator inputs a user ID, or e-mail address. 
At block 166, the administrator inputs a password, and at block 168 the 
administrator specifies a user, item or auction to which the relevant note 
pertains. The information inputted at blocks 164, 166 and 168 is subject to a 
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validation operation by the note creation function 102. 
[0047] At block 170, the administrator may then input specific information 
relevant to the note. Merely for example, the administrator may specify 
whether a user is to be suspended, fees are to be credited to the seller, 
bidders on the auction are to be e-mailed regarding an auction, and what the 
message type is. The administrator may also input pertinent text 
information, and select further participants, items or auctions to which the 
note appHes. 

[0048] At block 172, the administrator then submits the note content via the 
API 100. 

[0049] At decision block 176, a determination is made as to whether the note 
is valid by, for example, performing validation checks on the information 
inputted at blocks 164 - 172. If not, a rejection report is generated at block 
178. Alternatively, at block 180, the API 100, and specifically the note 
creation function 102, creates a record in the database 23, and specifically 
within the note table 48, associated with the specified participant item or 
auction. At block 182, an administrative function that invoked the note 
creation function 102 may perform other function specific operations (e.g., 
marking a user record as being suspended or removing an item from the 
auction facility 10 to update the database 23). The method 160 then ends at 
block 184. 

[0050] Figures llA - HE show various exemplary UI's, in the form of HTML 
or other mark-up language pages, that may be presented to an administrator 
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in the performance of the method 160. Figure llA shows an administrative 
application interface 190, utilizing which an administrator can select an 
administrative function to be performed. For example, via the interface 190, 
an administrator may select to end an auction, end all auctions for a seller, 
reinstate a blocked auction after review, deny appeal on a blocked item, 
remove an item, request a temporary password for a user, or rebalance a 
user account. These applications may be invoked by user selection of 
appropriate hypertext 192-204. 

[0051] Figure IIB illustrates an exemplary "end auction" UI 205, in the form 
of an HTML document, via which an administrator may be prompt for 
information regarding an auction, or multiple auction, to be ended. The UI 
205 may be presented in response to user selection of the hypertext 192 
illustrated in Figure llA. 

[0052] The UI 205 includes a user ID field 206, a password field 208 and an 
"auctions to end" field 210. An administrator may enter the identification 
numbers or codes for auctions to be entered into the field 210. The 
administrator is further given the option to suspend a user, credit fees to a 
seller, and e-mail bidders on an auction by selection of the appropriate radio 
buttons in the fields 212, 214 and 216. 

[0053] A "reason" field 218 includes a drop-down menu that presents a 
predetermined and authorized list of reasons for ending an auction for 
selection by the administrator. Finally, in the "text" field 220, an 
administrator may enter additional text or description regarding the ending 
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of the relevant auction or auctions. 

[0054] Figure IIC illustrates an exemplary embodiment of an "end member's 
auctions" user interface 224, in the form of an HTML document, using which 
an administrator may end all auctions of a particular participant, member or 
user of the auction facility 10. The UI 224 is similar to the UI 205 shown in 
Figure IIB, but differs in that an adnunistrator may, via a "user ID" field 230 
specifies the user ID, or e-mail address, of the user for which all auctions are 
to be ended. The UI 224 may, for example, be invoked by user selection of 
the hypertext 194 illustrated in Figure llA. 

[0055] Figure IID illustrates an exemplary "reinstate auction" UI 240, in the 
form of an HTML document, utilizing which an administrator may specify 
that an auction be reinstated. The UI 240 includes an "auction to reinstate" 
file 242 into which an administrator may input the item number of the 
subject auction, or other identifying information. A "reason" field 244 
presents a drop-down menu of a predetermined list of common or 
authorized reasons for reinstatement of an auction. The UI 240 may, merely 
for example, be invoked by user selection of the hypertext 196 illustrated in 
Figure llAB 

[0056] Figure HE illustrates an exemplary embodiment of an "appeal 
denied" UI 250, in the form of an HTML document, utilizing which an 
administrator can create a note as to why an appeal against the ending of an 
auction, or suspension of a user, was denied by the relevant administrator or 
by an appeal mechanism of the auction facility 10. The UI 250 represents a 
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"blocked item" field 252, into which the administrator inputs an item 
number, or other identifier, to specify an auction. A "reason" field 254 
presents a button on a menu of common, or authorized, reasons for the 
denial of an appeal. 

[0057] Any of the UI's, or interfaces, discussed above may further include an 
"expiration" field, into which an administrator may input a time period 
within which, or date by which, a relevant note will expire. This 
information may then populate the expiration field 82 of a note record 60. In 
a further embodiment, the expiration field 82 may be automatically 
populated by a housekeeping function. 

[0058] Figure 12 shows a diagrammatic representation of machine in the 
exemplary form of a computer system 300 within which a set of instructions, 
for causing the machine to perform any one of the methodologies discussed 
above, may be executed. In alternative embodiments, the machine may 
comprise a network router, a network switch, a network bridge. Personal 
Digital Assistant (PDA), a cellular telephone, a web appliance or any 
machine capable of executing a sequence of instructions that specify actions 
to be taken by that machine. 

{0059] The computer system 300 includes a processor 302, a main memory 
304 and a static memory 306, which communicate with each other via a bus 
308. The computer system 300 may further include a video display unit 310 
(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The 
computer system 300 also includes an alpha-numeric input device 312 (e.g. a 
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keyboard), a cursor control device 314 (e.g. a mouse), a disk drive unit 316, a 
signal generation device 318 (e.g. a speaker) and a network interface device 
320. 

[0060] The disk drive unit 316 includes a machine-readable medium 322 on 
which is stored a set of instructions (i.e., software) 324 embodying any one, 
or all, of the methodologies described above. The software 324 is also shown 
to reside, completely or at least partially, within the main memory 304 
and /or within the processor 302. The software 324 may further be 
transmitted or received via the network interface device 320. For the 
purposes of this specification, the term " machine-readable medium" shall be 
taken to include any medium which is capable of storing or encoding a 
sequence of instructions for execution by the machine and that cause the 
machine to perform any one of the methodologies of the present invention. 
The term "machine-readable medium" shall accordingly be taken to 
included, but not be limited to, solid-state memories, optical and magnetic 
disks, and carrier wave signals. 

[0061] Thus, a method and system for communicating information within a 
network-based auction facility have been described. Although the present 
invention has been described with reference to specific exemplary 
embodiments, it will be evident that various modifications and changes may 
be made to these embodiments without departing from the broader spirit 
and scope of the invention. Accordingly, the specification and drawings are 
to be regarded in an illustrative rather than a restrictive sense. 
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